45 research outputs found
Description Logics of Context with Rigid Roles Revisited
To represent and reason about contextualized knowledge often two-dimensional Description Logics (DLs) are employed, where one DL is used to describe contexts (or possible worlds) and the other DL is used to describe the objects, i.e. the relational structure of the specific contexts. Previous approaches for DLs of context that combined pairs of DLs resulted in undecidability in those cases where so-called rigid roles are admitted, i.e. if parts of the relational structure are the same in all contexts. In this paper, we present a novel combination of pairs of DLs and show that reasoning stays decidable even in the presence of rigid roles. We give complexity results for various combinations of DLs involving ALC, SHOQ, and EL
Stateful Greybox Fuzzing
Many bugs in protocol implementations may only manifest when the system is in
a particular "state". For instance, to trigger one of the bugs we found in an
RTSP implementation, the fuzzer must first send two different types of messages
to usher the protocol implementation from the INIT via the READY to the PLAY
state where the bug is exposed. Without knowledge of the protocol, it is
inherently difficult for a fuzzer to discover such stateful bugs. A key
challenge in fuzzing stateful systems, therefore, is to cover the state space
without an explicit specification of the protocol.
So, how can we help our fuzzer navigate an unknown state space? In our
analysis of the Top-50 most widely used open-source protocol implementations,
we found that every implementation uses state variables that are assigned named
constants (such as INIT, READY) to represent the current state. In this work,
we propose to automatically identify such state variables and track the
sequence of values assigned to them during fuzzing to produce a "map" of the
explored state space. Our stateful greybox fuzzing approach uses this map to
focus on the most promising regions of the code and state space.
Our experiments confirm that our stateful fuzzer discovers stateful bugs
twice as fast as the baseline greybox fuzzer that we extended. The state
sequence for an input is determined by the sequence of values assigned to the
state variables during its execution. Starting from the initial state, our
fuzzer exercises one order of magnitude more state sequences and covers the
same code two times faster than the baseline fuzzer. Several zero-day bugs in
prominent protocol implementations were found by our fuzzer, and 8 CVEs have
been assigned
Locating Faults with Program Slicing: An Empirical Analysis
Statistical fault localization is an easily deployed technique for quickly
determining candidates for faulty code locations. If a human programmer has to
search the fault beyond the top candidate locations, though, more traditional
techniques of following dependencies along dynamic slices may be better suited.
In a large study of 457 bugs (369 single faults and 88 multiple faults) in 46
open source C programs, we compare the effectiveness of statistical fault
localization against dynamic slicing. For single faults, we find that dynamic
slicing was eight percentage points more effective than the best performing
statistical debugging formula; for 66% of the bugs, dynamic slicing finds the
fault earlier than the best performing statistical debugging formula. In our
evaluation, dynamic slicing is more effective for programs with single fault,
but statistical debugging performs better on multiple faults. Best results,
however, are obtained by a hybrid approach: If programmers first examine at
most the top five most suspicious locations from statistical debugging, and
then switch to dynamic slices, on average, they will need to examine 15% (30
lines) of the code. These findings hold for 18 most effective statistical
debugging formulas and our results are independent of the number of faults
(i.e. single or multiple faults) and error type (i.e. artificial or real
errors)
FairFuzz: Targeting Rare Branches to Rapidly Increase Greybox Fuzz Testing Coverage
In recent years, fuzz testing has proven itself to be one of the most
effective techniques for finding correctness bugs and security vulnerabilities
in practice. One particular fuzz testing tool, American Fuzzy Lop or AFL, has
become popular thanks to its ease-of-use and bug-finding power. However, AFL
remains limited in the depth of program coverage it achieves, in particular
because it does not consider which parts of program inputs should not be
mutated in order to maintain deep program coverage. We propose an approach,
FairFuzz, that helps alleviate this limitation in two key steps. First,
FairFuzz automatically prioritizes inputs exercising rare parts of the program
under test. Second, it automatically adjusts the mutation of inputs so that the
mutated inputs are more likely to exercise these same rare parts of the
program. We conduct evaluation on real-world programs against state-of-the-art
versions of AFL, thoroughly repeating experiments to get good measures of
variability. We find that on certain benchmarks FairFuzz shows significant
coverage increases after 24 hours compared to state-of-the-art versions of AFL,
while on others it achieves high program coverage at a significantly faster
rate
Locating Faults with Program Slicing: An Empirical Analysis
Statistical fault localization is an easily deployed technique for quickly determining candidates for faulty code locations. If a human programmer has to search the fault beyond the top candidate locations, though, more traditional techniques of following dependencies along dynamic slices may be better suited. In a large study of 457 bugs (369 single faults and 88 multiple faults) in 46 open-source C programs, we compare the effectiveness of statistical fault localization against dynamic slicing. For single faults, we find that dynamic slicing was eight percentage points more effective than the best per- forming statistical debugging formula; for 66% of the bugs, dynamic slicing finds the fault earlier than the best performing statistical debugging formula. In our evaluation, dynamic slicing is more effective for programs with single fault, but statistical debugging performs better on multiple faults. Best results, however, are obtained by a hybrid approach: If programmers first examine at most the top five most suspicious locations from statistical debugging, and
then switch to dynamic slices, on average, they will need to examine 15% (30 lines) of the code. These findings hold for 18 most effective statistical debugging formulas and our results are independent of the number of faults (i.e. single or multiple faults) and error type (i.e. artificial or real errors)